One of the emerging communication technologies for delivering multimedia services across fixed and mobile access networks is the IP Multimedia Subsystem (IMS). The network architecture according to IMS comprises a service layer, control and connectivity layers, and an access layer. The control layer comprises call session control functions (CSCFs) forming central nodes for the provision of the SIP signaling (SIP: Session Initiation Protocol). The SIP protocol is one of the core technologies used by IMS for controlling the multimedia sessions combining voice and data streams.
A further core component of the IMS network architecture is the Service Capability Interaction Manager (SCIM) which was introduced in the 3GPP TS 23.002 standard as a function within a SIP Application Server domain of the IMS architecture. The role of the SCIM is that of a service broker in more complex service interaction scenarios which cannot be supported through the service filtering mechanism. The SCIM as proposed to the 3GPP uses an ISC interface to enable composite service behavior leveraging simpler service capabilities. In practical terms, a “capability” is a system component that may be used, presumably with other components, to implement a “service” that is packaged and delivered to end users of the network. For example, a group list server and a presence server may both be considered “capabilities” that are used to implement a sophisticated conferencing service. In this regard, an open issue in the 3GPP Release 9 specification is the orchestration of interaction between “capabilities” in the larger network which are represented as SIP Application Server instances.
SCIM can be implemented using service composition approach, where services, also called constituent services, may be aggregated to composite services. Composite services address complex user requirements that usually can not be covered by existing services. Hence, composite services offer added value in the form of new functionality compared to the sum of the functionality of their building blocks.
By way of example, some basic services and enablers may enable a weather forecasting service and a positioning data service. Both can be used individually, however combining them into a composite service that provides a location based weather forecast creates a new type of functionality with an added value. For this reason, composite services are often referred to as value added services. A location based service, in this example a location based weather forecast, may be created out of two existing components, namely an enabler that provides location information and a weather forecast service.
The exposure of these functions, such as SOA services (SOA: service oriented architecture), allows an application to individually discover them by querying a service repository and then individually bind these services. The process of discovering appropriate services as well as the far more complex logic for binding these services and making use of their functionality is implemented in the application itself. The developer of the application logic may consider and cover all eventualities at design time, e.g. faulty services, possibly a number of different technologies/formats, and a host of other issues that are not directly related to the actual end-user service, but rather to the usage of the enabling services.
The service composition functionality usually introduces an entity—the service composition engine—that takes care of this complexity for the application. In this scenario the application implements just its core logic, whereas the enabling functionality such as the “location-based weather forecast” is exposed by the composition engine as a single service that may be easily discovered and bound by the application. In the given example, the composition engine executes application logic in the form of the definition of the composite service “location-based weather forecast”. This composite service describes the type of required services, so that the engine—in particular at run-time—may discover, bind and execute appropriate services. Composition functionality, consequently, allows for great flexibility e.g. in handling events such as a faulty enabler. In this case, the engine could bind an alternative service without any disruption of the end-user application.
A service composition may enable the decoupling of application logic and enabling further functions. By extracting parts of the logic from the application and implementing it in a formalized way with the help of a composition entity, i.e. engine, a number of advantages become possible. The application logic becomes easily reusable and adaptable, it also becomes easier to implement since it may make use of the event-driven facilities of the composition engine.
Decoupling of application logic and exposure of functionality as reusable services is clearly facilitated by component-based software development and modeling of the application functionality. On the one hand, software components or groups thereof already represent cleanly defined units of functionality i.e. good candidates for services. Consequently, understanding the application functionality based on its modeling is the basic requirement for defining aggregate application functionality in a composition.
Clearly, composition sessions may contain data. These data are usually manipulated by the process according to instruction in its composite service description, i.e. according to a wish of a composite service designer. The data is either directly manipulated by these instructions, e.g. assigning a value to a variable, or indirectly, e.g. as results of services invocations. Sometimes, this kind of composition session state data is also called “Shared State Data”, because they represent the state shared between all services participating in a given composition session.
IMS was designed to deliver real-time, e.g. voice, and soft-real-time, e.g. SMS, services to customers. Accordingly, all nodes including SCIM should fulfill real-time or at least soft-real-time requirements, wherein, according to frequent customer requirements, a latency imposed by a SCIM node during an IMS call establishment may not exceed few dozens of milliseconds. However, with increased complexity of the composite services, the additional latency introduced by the SCIM may become a challenging issue. One of the main sources of additional latency is the invocation of constituent services. In this regard, latency is sum of time required by the constituent service to execute its internal logic and of the network latency between SCIM node and the constituent service. In networks with more then one SCIM node, the selection of the SCIM node for execution of composite service may also have an impact on a latency of a composite service.
Accordingly, there is a need for efficiently managing an execution of a composite service in a communication network in which service execution nodes, e.g. composition engines, are provided for executing constituent services of the composite service.